home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / ClearPartStorage < prev    next >
Encoding:
Internet Message Format  |  1996-07-24  |  2.2 KB  |  [TEXT/ttxt]
  1. Subject:     ClearPartStorage
  2. Sent:        7/24/96 8:56 AM
  3. Received:    7/24/96 9:10 AM
  4. From:        Henri Lamiraux, lamiraux@apple.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. This message was returned to me with an error. I am resending it.
  9.  
  10. ------------------------------------------------------------------
  11.  
  12. As I think Arni noted, the ODF practice of removing the part's prefered
  13. kind and then letting the part externalize is causing severe document
  14. bloat. Bento is not reclaiming the space very well.
  15.  
  16. My own results... With 6 ODF based Rapid-I Button parts (with picture
  17. labels and script actions) embedded in ODF Container, I can account for
  18. about 200K of needed storage. After making a single change to the 
  19. document,
  20. it bloats out to > 400K. Doing a "Save a Copy..." reduces the document 
  21. size
  22. down to just over 200K.
  23.  
  24. I think what's happening here is that if a silly little change is made to
  25. an inconsequential little part, each part has to externalize itself. Thus,
  26. each ODF part clobbers its old contents property, and Bento lets the
  27. document size double.
  28.  
  29. A good solution might be an "fPartChanged" flag in FW_CPart, set when
  30. FW_CPart::Changed is called. Right now, that method just flags the 
  31. document
  32. as dirty. If a part is unchanged, then it has no work to do at
  33. externalization time.
  34.  
  35. Now, for those of us caching data in frames, it would also be useful to
  36. have a changed flag just for each FW_CFrame, so that we don't have to
  37. externalize cache data for a frame that hasn't changed.
  38.  
  39. This whole solution would also cut down on externalization time of ODF
  40. parts. With lots of parts in a document, the time savings could be
  41. significant.
  42.  
  43. So, does this make any sense?
  44.  
  45. Brad
  46.  
  47. <mailto: "Brad Hutchings" brad@hutchings-software.com>
  48. <http://www.hutchings-software.com>
  49.  
  50. Got OpenDoc? Got Cyberdog? Then beta-test Rapid-I Button! Email me for 
  51. more
  52. information...
  53.  
  54.  
  55. ........................................................................
  56.  Henri Lamiraux                                      lamiraux@apple.com
  57.  Apple Computer, Inc.                 OpenDoc(tm) Development Framework
  58. ........................................................................
  59.  
  60.  
  61.